home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
QRZ! Ham Radio 4
/
QRZ Ham Radio Callsign Database - Volume 4.iso
/
digests
/
packet
/
940065.txt
< prev
next >
Wrap
Internet Message Format
|
1994-11-13
|
7KB
Date: Thu, 4 Aug 94 04:30:01 PDT
From: Packet-Radio Mailing List and Newsgroup <packet-radio@ucsd.edu>
Errors-To: Packet-Radio-Errors@UCSD.Edu
Reply-To: Packet-Radio@UCSD.Edu
Precedence: Bulk
Subject: Packet-Radio Digest V94 #65
To: packet-radio
Packet-Radio Digest Thu, 4 Aug 94 Volume 94 : Issue 65
Today's Topics:
NA vs NAOM
proxy ARP with NOS ?
Send Replies or notes for publication to: <Packet-Radio@UCSD.Edu>
Send subscription requests to: <Packet-Radio-REQUEST@UCSD.Edu>
Problems you can't solve otherwise to brian@ucsd.edu.
Archives of past issues of the Packet-Radio Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".
We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party. Your mileage may vary. So there.
----------------------------------------------------------------------
Date: 3 Aug 94 20:59:15 GMT
From: news-mail-gateway@ucsd.edu
Subject: NA vs NAOM
To: packet-radio@ucsd.edu
KD3O.MD.USA
This is a copy of W3IWI's (Tom's) bulletin on NOAM vs NA he sent out a few
years ago you mentioned.
73's Jim KD3O KD3O.MD.USA
Several people have asked about the .NOAM appearing in the W3IWI message
head-
ers. Rather than answer the inquiries separately, I thought it would be
useful
to circulate the text of one of the papers I presented at the September ARRL/
CRRL 9th Networking Conference held in London, Ontario (with a few minor
changes and updates). So far I have had no complaints about my use of
.NOAM
and a few others (including TI0PAQ in .CEAM) have started following the
suggestion.
73, Tom
_________________
Some comments on the "H"ierarchical Continent Address Designator
_________________
Tom Clark, W3IWI
6388 Guilford Road
Clarksville, MD 21029
At the risk of opening Pandorra's Box, this note suggests a change in the 2-
character continent designator portion of the PBBS "H" hierarchical address
field. An example would be the North America .NA portion of the packet ad-
dress,
K9DOG . W6SIX.DE.USA.NA
Let me state at the outset that I'm not convinced that we need to use the
continent field. It seems to me that the country field by itself is adequate
and that the packet BBSes can easily keep track of all the countries in the
world. Let me also state that many of the issues addressed here arise because
of constant confusion between the functions of addressing and routing.
The correct continent to assign to many countries of the world is confusing
and/or ambiguous. To cite some examples of problems which have already been
identified:
- 5B4=Cyprus in the Mediterranian is listed by the IARU (for WAC)
and the ITU as Asia. Ditto 4X=Israel and JY=Jordan in the middle
East.
- Both TA=Turkey and the Soviet Union have part of their coun-
ties in Europe and part in Asia. 8Q6=Maldives is listed as both
Africa and Asia. Several other countries are also "split".
- Although DU=Philipines and YB=Indonesia are regarded as Asiatic
countries, the are listed as Oceania, along with Australia and
Hawaii. If you venture to 9M=Malasia, you may be in either Ocea-
nia or Asia.
- The Central American and Carribean countries are nearly all part
of North America, including YV0, but not 9Y. Anyone care to guess
what continent the southern part of HP=Panama is in?
If the purpose of the continent portion of the "H"ierarchical address is to
facilitate delivery of messages, then it is illogical to route Israeli and
Jordanian traffic through the Orient. It is illogical to make automated rout-
ing decisions for messages to Turkish amateurs based on whether the addressee
is on the east or west side of the Straits of Bosporus.
Stations in Israel and Cyprus already face this dilemma. Rather than using
a .AS Asian address, they choose to use .EU European designator to avoid
having their packet mail routed via the Orient. Some have suggested the
use of
a new continent designator other than .AS; One suggestion has been .ME
(Middle
East) but this has a serious conflict with the state of Maine.
The Central Americans and the Carribean are both "legally" .NA but feel they
need a separate geographic identity and both areas have independently
suggest-
ed the use of .CA but this would conflict with .CA state.
All this leads to my suggestion that the present 2-letter continent
designator
must be changed. Either:
(1). The present 2-character designator should be dropped because it
it not really needed and there are too many ambiguities. Users
will always try to use address quirks to force routing, so don't
give them the chance to foul things up. The computers at the
international mail gateways can easily handle the entire DXCC
list.
- or -
(2). A new logical regional designator which allows sub-continent
sized regions should be adopted.
If a new, more flexible scheme is to be adopted, I'd suggest that new 4-
character designators be chosen:
- .NOAM, .SOAM, .CEAM, .CARB replacing the present .NA & .SA and
solving the Central American and Carribean problem,
- .ASIA replacing .AS for the Orient,
- .MDLE for the middle-eastern countries like 4X, JY etc.,
- Oceania divided into smaller areas like .NPAC, .SPAC, .AUST,
- The Indian ocean (now partly in .OC and partly in .AF) be desig-
nated .INDI,
- .AFRI replacing .AF for Africa; .EURO replacing .EU for Europe,
- .ANTR added for Antarctica,
- Additional new designators added as needed for sub-continent
sized logical areas.
This scheme affords the logic of a 2-character field (.MD) for the
"state", 3
characters (.USA, .ZAF, .JPN etc.) for the country, & 4 (.AFRI) for the
conti-
nent/subcontinent, and it avoids conflicts between state and province-sized
areas and continents. Who knows, a few decades hence a 5 character field
(.EARTH, .VENUS) may be needed too!
[Note: Because of issues raised in this note, the W3IWI PBBS does
not use the .NA continent designator on any of its own transac-
tions, although it transparently passes any originated
elsewhere].
--------------------- end of bulletin by w3iwi ------------------------
------------------------------
Date: 4 Aug 94 08:07:57 GMT
From: news-mail-gateway@ucsd.edu
Subject: proxy ARP with NOS ?
To: packet-radio@ucsd.edu
Is there any version of ka9q NOS that can handle proxy ARP ?
/Peter SM0OHI
------------------------------
End of Packet-Radio Digest V94 #65
******************************